home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / cell-relay-faq < prev    next >
Internet Message Format  |  1993-12-02  |  48KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kei.com!eff!news.umbc.edu!haven.umd.edu!umd5.umd.edu!not-for-mail
  2. From: carl@umd5.umd.edu (Carl Symborski)
  3. Newsgroups: comp.dcom.cell-relay,comp.answers,news.answers
  4. Subject: comp.dcom.cell-relay FAQ: ATM, SMDS, and related technologies
  5. Followup-To: comp.dcom.cell-relay
  6. Date: 1 Dec 1993 02:37:00 -0500
  7. Organization: University of Maryland, College Park
  8. Lines: 1107
  9. Sender: carl@macbeth.umd.edu
  10. Approved: news-answers-request@MIT.Edu
  11. Message-ID: <2dhhis$6vb@macbeth.umd.edu>
  12. NNTP-Posting-Host: macbeth.umd.edu
  13. Summary: General information and answers to questions related to or seen
  14.          in the comp.dcom.cell-relay group.
  15. Keywords: cell-relay, ATM, SMDS, communications
  16. Xref: senator-bedfellow.mit.edu comp.dcom.cell-relay:2359 comp.answers:2860 news.answers:15247
  17.  
  18. Archive-name: cell-relay-faq
  19. Last-modified: 1993/11/30
  20.  
  21. FAQ-Maintainer: Carl Symborski (carl@umd5.umd.edu)
  22.  
  23. This article mostly contains general information but also answers to some 
  24. Frequently Asked Questions (FAQ) which are related to or have been seen in 
  25. comp.dcom.cell-relay.  It is posted to provide information of general 
  26. interest to both new and experienced readers. 
  27.  
  28. This list includes answers to questions, which are loosely grouped into 
  29. categories.  Questions marked with a "+" are new in this issue; those with 
  30. significant changes of content since the last issue are marked by "*":
  31.  
  32.  A)  TOPIC: COMP.DCOM.CELL-RELAY BASIC INFORMATION
  33.   A1)   What is the CELL-RELAY group?
  34.   A2) * What is the archive site for this group?
  35.   A3) * Is there a parallel mailing list for this group?
  36.   A4) * What other mailing lists are related to ATM?
  37.  B)  TOPIC: INDUSTRY FORUMS AND VENDOR INFORMATION
  38.   B1) * How can I contact the ATM Forum?
  39.   B2) * What vendors are working on ATM technology?
  40.   B3)   What vendors are working on ATM hardware/chips?
  41.   B4)   What vendors are selling ATM test equipment?
  42.   B5)   Are there any ATM interface boards for PCs?
  43.   B6)   Where are the ATM Forum's FTP sites and mailing lists?
  44.  C)  TOPIC: ATM REFERENCES 
  45.   C1)   What are some good getting started ATM references?
  46.   C2)   Where/What is the "Network Compatible ATM for LANs" document?
  47.   C3)   Where are hosts with ATM related information?
  48.   C4) * How can I get the ATM Forum's Interface Specifications?
  49.   C5) * List of ITU-TS Recommendations concerning ATM.
  50.   C6) * Internet drafts from IETF working groups.
  51.   C7) * ATM Tutorials.
  52.   C8)   Contact information for ANSI T1S1 specifications.
  53.   C9)   Internet RFCs.
  54.   C10)+ ATM and Related Acronyms.
  55.  D)  TOPIC: ATM TECHNOLOGY QUESTIONS
  56.   D1)   What are the various ATM Access layers?
  57.   D2)   Are ATM cells delivered in order?
  58.   D3)   What do people mean by the term "traffic shaping"?
  59.   D4)   What is happening with signalling standards for ATM?
  60.   D5)   What is VPI and VCI?
  61.   D6)   Why both VPI *and* VCI?
  62.   D7)   How come an ATM cell is 53 bytes anyway?
  63.   D8)   How does AAL5 work?
  64.   D9)   What are the diffferences between Q.93B and Q.931?
  65.  E)  TOPIC: ATM VS. XYZ TECHNOLOGY
  66.   E1)   How does ATM differ from SMDS?
  67.  F)+ TOPIC: FREELY AVAILABLE REFERENCE IMPLEMENTATIONS
  68.   F1) + What and where is VINCE?
  69.  
  70. If you have suggestions or corrections for any of these answers or any
  71. additional information, please send them directly to carl@umd5.umd.edu;
  72. the information will be included in the next revision (or possibly the one
  73. after that).
  74.  
  75. This posting is intended to be distributed every few months. New versions 
  76. are archived along with other comp.dcom.cell-relay traffic on 
  77. cell-relay.indiana.edu.  See subject A2 for instructions to access the
  78. archive.
  79.  
  80. The information contained herein has been gathered from a variety of sources.
  81. Most derived from a consensus of postings on the group.  A listing of 
  82. contributors so far can be found at the end of the FAQ text. If you would 
  83. like to claim responsibility for a particular item, please let me know.
  84.  
  85. Enjoy!
  86.  
  87. Carl Symborski                              Alguien tiene que escuchar
  88. carl@umd5.umd.edu                           Oye este canto que ya va a empezar
  89.  
  90.  
  91. -----------------------------------------------------------------------------
  92. TOPIC:     A)   TOPIC: COMP.DCOM.CELL-RELAY BASIC INFORMATION
  93. -----------------------------------------------------------------------------
  94. SUBJECT:  A1)   What is the CELL-RELAY group?
  95.  
  96.     The purpose of this group is to provide a forum for the submission
  97. of articles and inquiries dealing with networks using Cell Relay as a 
  98. transport; including local, metropolitan, and wide area networks.  The
  99. name cell-relay was chosen as a compromise over objections to the name
  100. "ATM" during the creation of this group.  The acronym ATM in the context of
  101. this group stands for Asynchronous Transfer Mode, not Automatic Teller 
  102. Machines or Adobe Type Manager.  The term "cell" in cell-relay is taken to 
  103. mean a small, fixed sized, information bearing unit that provides the 
  104. foundation for transport and multiplexing of user traffic.  This topic 
  105. area is not related to cellular phones or intra-cellular organisms.
  106.  
  107.  
  108. SUBJECT:  A2) * What is the archive site for this group?
  109.  
  110.     The archives for comp.dcom.cell-relay are available via anonymous 
  111. ftp to cell-relay.indiana.edu as:
  112.  
  113.     /pub/cell-relay/archive/YY-MM.mbox
  114.  
  115. where YY=year and MM=month.  There are available in both
  116. compressed and normal formats.
  117.  
  118.  
  119. SUBJECT:  A3) * Is there a parallel mailing list for this group?
  120.  
  121.     A direct mailing list has been setup which is a mirror of the USEnet
  122. newsgroup comp.dcom.cell-relay. To send mail TO the list, send it to:
  123.  
  124.     comp.dcom.cell-relay@indiana.edu
  125.  
  126. To un/subscribe, or send other notes to the list management, please use:
  127.  
  128.         cell-relay-request@indiana.edu
  129.  
  130.  
  131. SUBJECT:  A4) * What other mailing lists are related to ATM?
  132.  
  133.     There are several lists described below.  One is for an IETF group 
  134. working on the issue of IP over ATM.  This work is on going and primarily 
  135. focused on that task.  General ATM questions and blue-skying are inappropriate
  136. and discouraged by the members on the list.  To send mail TO the list, send 
  137. it to:
  138.  
  139.     atm@hpl.hp.com
  140.  
  141. To un/subscribe, or send other notes to the list management, use the address:
  142.  
  143.     atm-request@hpl.hp.com
  144.  
  145.     Related to cell-relay technology is the Distributed Queueing mailing
  146. list.  The distributed queueing list is intended for discussion about protocol
  147. design, variants, extensions, associated with the use of DQ for arbitrating
  148. access to cells in shared-medium cell-relay networks.  To send mail TO the 
  149. list, sent it to:
  150.  
  151.     dqlist@atri.curtin.edu.au
  152.  
  153. To un/subscribe, or send other notes to the list management, use the address:
  154.  
  155.     dqlist-request@atri.curtin.edu.au
  156.  
  157.         Another IETF working group is working on the issue of general routing
  158. over networks (large clouds).  As with the IP over ATM list it is best to
  159. subscribe with the intention to just "listen in".  To un/subscribe to this
  160. list use the address:
  161.     
  162.         rolc-request@nsco.netcom.com 
  163.  
  164.     Also of possible interest is the mailing list for the SMDS special
  165. interest group (SIG) Technical Committee.  To send mail TO the list, send
  166. it to:
  167.  
  168.     smdstc@nsco.network.com
  169.  
  170. To un/subscribe, or send other notes to the list management, use the address:
  171.  
  172.     smdstc-request@nsco.network.com
  173.     
  174.  
  175. -----------------------------------------------------------------------------
  176. TOPIC:     B)   INDUSTRY FORUMS AND VENDOR INFORMATION
  177. -----------------------------------------------------------------------------
  178. SUBJECT:  B1) * How can I contact the ATM Forum?
  179.     
  180.     Similar to the Frame Relay Forum, the ATM Forum is an open public 
  181. forum with over 300 contributing and auditing companies.  Membership
  182. includes many international companies.  Some companies also
  183. participate in ANSI T1S1 and other standards bodies.  Audit membership of the 
  184. Forum is $1500/year.  Those interested in joining the forum or needing
  185. additional information should contact:
  186.  
  187. The ATM Forum
  188. 480 San Antonio Road, Suite 100
  189. Mountain View, CA 94040-1219  U.S.A
  190. Tel +1 415-962-2585
  191. Fax +1 415-941-0849
  192. Email atmforum_info@atmforum.com
  193.  
  194. The ATM Forum also has a FAX-On-Demand service.  Using this it is possible to
  195. get instructions, order forms, membership applications, etc.  Just dial
  196. +1 415-688-4318 from a FAX phone and follow the instructions.
  197.  
  198.  
  199. SUBJECT:  B2) * What vendors are working on ATM technology?
  200.  
  201.     It is tough to get a number on this.  Increasingly there are companies
  202. with hardware they can demonstrate.  More who have made product announcements.
  203. Many more who have stated product intentions.  Some are building big
  204. central office switches, others smaller ones for the LAN market.  Workstation
  205. vendors are working on ATM interface boards.  Chip companies are working on
  206. ATM chip sets, etc.  There are now software vendors advertizing protocol
  207. software stacks (Q.93B, etc.) suitable for inclusion in ATM products.
  208.  
  209. Previously (in 1992) there was an attempt here to list most of the major 
  210. players in the ATM arena.  This was possible in 1992.  At this time 
  211. *everyone* is doing something or paying lip service to ATM.  It is simply 
  212. not practical to keep a fair and accurate list here in this FAQ.
  213.  
  214. Some postings on the cell-relay list (Fall 1993) attempted to again list the
  215. current vendors developing and/or selling equipment in this technology area.
  216. As predicted, these partial lists exceeded 40 vendors!
  217.  
  218.  
  219. SUBJECT:  B3)   What vendors are working on ATM hardware/chips?
  220.  
  221.         As with ATM technology vendors, the number of companies developing
  222. board level components is growing and soon will be hard to track.  
  223.  
  224. For starters, there is a group in North America working on low-cost 
  225. SONET-based ATM physical layer chips for local nets using optics and twisted 
  226. pair interfaces.  This group is called the Saturn Development Group, and 
  227. consists of PMC-Sierra, Sun Microsystems, Ungermann-Bass, Bell-Northern 
  228. Research, Interphase, Optical Data Systems, SynOptics Communications, 
  229. Themis Computer, BBN, MPR Tetltech, the University of 
  230. British Columbia, and maby others.  Contact PMC-Sierra for information: 
  231.  
  232.         PMC-Sierra, Inc.
  233.         8999 Nelson Way
  234.         Burnaby, BC
  235.         Canada V5A 4B5
  236.         604-293-5755 
  237.  
  238. Adaptive has designed an ATM/AAL chipset for use in equipment (computer, 
  239. workstation, router, etc.) which connects to an ATM network.  That chipset
  240. is now licenced to two chip manufacturers, TransSwitch and National
  241. Semiconductor.  The TransSwitch product is called SARA and consists of a
  242. segmentation chip and reassembly chip.  Together they can form the basis of
  243. an ATM/AAL controller which can process up to 8000 packets simultaneously 
  244. at speeds of up to 155.52 Mbit/s.  The chip set implements BISDN adaptation 
  245. layers AAL3/4 and AAL5 in addition to supporting constant bit rate 
  246. (CBR) traffic.  Presumably the National Semiconductor product is similar.
  247.  
  248. Fujitsu makes a 4 x 4 switch element chip set (MB86680).
  249.  
  250.  
  251. SUBJECT:  B4)   What vendors are selling ATM test equipment?
  252.  
  253.          There exist already a number of vendors that hava ATM test equipment
  254. available. To name a few:
  255.  
  256. 1. ATM-100, Wandel & Goltermann
  257.     Tel.: +49 7121-862143
  258.     Fax.: +49 7121-862054
  259.  
  260. 2. ATM Test Tool, Siemens AG
  261.     Tel.: +49 30-386-4173
  262.                      7077
  263.     Fax.: +49 30-386-7934
  264.     The Siemens tool is the same as the Wandel & Goltermann tool
  265.  
  266. 3. HP 75000 Series 90 ATM Analyzer, contact your local Hewlett Packard sales
  267.     office
  268.  
  269. 4. HP Broadband Series protocol test system, 
  270.     IDACOM Telecom Division,
  271.     Hewlett Packard (Canada) Ltd.
  272.     Edmonton, Alberta
  273.     Canada T6E 5R6
  274.     Tel.: +1-800-661-3868
  275.           +1-403-462-4545
  276.     Fax.: +1-403-462-4869 
  277.  
  278. 5. Alcatel 8643 ATM Traffic Generator Analyzer, and Alcatel 8640, Alcatel STR, 
  279.     Tel.: +41 1 4652860
  280.     Fax.: +41 1 4652319
  281.     or Alcatel Network Systems Inc., Richardson, TX
  282.     Tel.: +1 214-996-5000
  283.     Fax.: +1 214-996-5409
  284.  
  285. 6. Adtech AX/3000 ATM Cell Data Generator, AX/3010 DS3 ATM Cell Data Generator
  286.         1814 Algaroba St,
  287.         Honolulu HI 96826
  288.         Tel.: (808) 941-0708
  289.         Fax.: (808) 946-1300
  290.  
  291. This list is provided for information purposes only.  There is no implied 
  292. claim that this list is correct or complete.
  293.  
  294.  
  295.  
  296. SUBJECT:  B5)   Are there any ATM interface boards for PCs?
  297.  
  298.         National Semiconductor has an ESIA ATM card (Vicksburg DP8300VK) which
  299. will be available in November 1993.  NET will resell the board.  Also, at the
  300. August 1993 Interop IBM was demonstrating their PS/2 based ATM cards.
  301.  
  302.  
  303. SUBJECT:  B6)   Where are the ATM Forum's FTP sites and mailing lists?
  304.  
  305.         The ATM Forum is a members only organization.  Although an open public
  306. forum (which means that anyone can join) only members have direct access to 
  307. Forum activities and documentation. There are *NO* FTP sites and *NO* open 
  308. e-mail lists.  
  309.  
  310.         Note that the minimal entry to the Forum is as an Auditing Member.  
  311. Auditing Members are allowed access to the e-mail distribution lists to "audit"
  312. all documentation but are NOT ALLOWED to make comments.  Please note that 
  313. auditing members are not allowed to attend Technical and Market Commitee 
  314. meetings, not allowed to vote on issues and not allowed to submit technical 
  315. contributions.  See subject B1 for ATM Forum membership information. 
  316.  
  317.  
  318. -----------------------------------------------------------------------------
  319. TOPIC:     C)   ATM REFERENCES
  320. -----------------------------------------------------------------------------
  321. SUBJECT:  C1) * What are some good getting started ATM references?
  322.  
  323.     Generally it is impossible  to pick up any communications related 
  324. technical journal, conference, or trade publications and not find something 
  325. about ATM.  Most of what has been written in the 1985 through 1990 time frame 
  326. primarily deals with the application of ATM to Broadband ISDN.  These provide 
  327. the foundation on which other applications of ATM have been based and therefore
  328. should not be over looked.
  329.  
  330. Without a doubt, if you are at all serious about learning ATM, the best 
  331. references are the series of specifications developed by the ATM Forum.
  332. These are the:
  333.  
  334.     o ATM User-Network Interface Specification, Ver 3.0, September 10, 1993
  335.     o The ATM Forum BISDN Inter Carrier Interface (B-ICI) Specification, 
  336.         Ver 1.0 August, 1993
  337.  
  338. The ATM Forum's DXI specification is also useful.  See subject C4 for 
  339. ways to obtain these documents.    
  340.  
  341. Note that because of the pace of ATM standardization, reference books rapidly
  342. become out-of-date.  Specifically, there have been major changes to the
  343. specification of the AALs subsequent to the publication of these books and
  344. articles.  However, the following references do offer a good base of 
  345. background information.  Note, see also subject C7 for ATM Tutorials.
  346.  
  347. --General:
  348.  
  349. "Data Communications Special Guide", IEEE Spectrum, 8/91, p.22.
  350.    o Hi-level overview of high-speed lans, wans, bisdn, atm, with glossary
  351.      and bibliography.
  352.  
  353. IEEE Communications Magazine, April 1992, VOL. 30, NO. 4
  354.    o This is a special issue with six articles on gigabit networks technology.
  355.  
  356. "Cell Relay Switching", Data Communications, 9/91, p.58.
  357.    o Looks at cell relay and switching in general, not just ATM.
  358.  
  359. Rainer Handel and Manfred Huber. "Integrated Broadband Networks: An
  360.    Introduction to ATM-Based Networks". Addison-Wesley, 1991.
  361.    ISBN 0-201-54444-X.
  362.  
  363.  
  364. --ATM:
  365.  
  366. "Overview of ATM Networks: functions and procedures", Computer Communications,
  367.    12/91, p.615.
  368.    o Cell headers, bit definitions and the like. 33 References, including
  369.      good list of CCITT recommendations.
  370.  
  371. "Broadband ISDN and Asynchronous Transfer Mode (ATM)", IEEE Communications,
  372.    9/89.
  373.    o Describes most of the jargon as well as the paradigm and unresolved
  374.      issues.  One point to note is that the article is fairly old (1989) and
  375.      some things have changed.  For example, the ATM cell headers described
  376.    are no longer valid.
  377.   
  378. "Asynchronous Transfer Mode: Solution for Broadband ISDN", Martin de Prycker,
  379.    Ellis Horwood, New York, 1991.  ISBN 0-13-053513-3
  380.    o See Martin's more recent book below.
  381.  
  382. "Asynchronous Transfer Mode", Martin De Prycker, Ellis Horwood, New York
  383.    1993, ISBN 0-13-178542-7.
  384.    o Very readable general description of the technology and optimization.
  385.      Even though its recent some of the details have changed AND the book 
  386.      is NOT long on details. Also, this is primarily an ITU-oriented 
  387.      (telecomm services) view of ATM, not an ATM Forum-oriented view (CPE), I 
  388.      believe.
  389.   
  390. "Gigabit Networking", Craig Partridge, Addison-Wesley, Reading MA, 
  391.    1993, ISBN 0-201-56333-9.
  392.    o Very well written book.  Craig is the Editor of "IEEE Network" magazine.
  393.      Topics: fiber optics, cell networking, ATM, Gbps packet schemes, 
  394.      applications, host interface, higher protocols, bandwidth management and 
  395.      performance, distributed systems, etc.
  396.  
  397.  
  398. --SWITCH FABRICS:
  399.  
  400. These papers offer a fast jump start on ATM switch architectures, design
  401. issues and tradeoffs.
  402.  
  403. H. Ahmadi and W. Denzel, "A Survey of Modern High-Performance Switching
  404.    Techniques", IEEE J on Selected Areas in Comm, Vol. 7, No. 7, Sept 1989, 
  405.    p. 1091-1103
  406.  
  407. F. Tobagi, "Fast Packet Switch Architectures for Broad-band Integrated
  408.    Services Digital Networks", Proceedings of IEEE, Vol. 78, No. 1, Jan. 1990
  409.    p. 133-167
  410.  
  411. Joseph Y. Hui, "Switching and Traffic Theory for Integrated Broadband 
  412.    Networks", Kluwer Academic Publishers, 1991,  ISBN 0-7923-9061-X
  413.    o A back to basics text book explaining core switching concepts like
  414.      batcher/banyon, clos, min, buffering, etc.
  415.  
  416.  
  417. Technical journals
  418. ==================
  419.         IEEE Network
  420.         IEEE Communications
  421.         IEEE Journal on Selected Areas in Communications
  422.         IEEE Transactions on Communications
  423.         IEEE/ACM Transactions on Networking
  424.         Computer Communication Review (by ACM SIGCOMM)
  425.         Computer Communications
  426.         Computer Networks and ISDN Systems
  427.         IEICE Transactions on Communications
  428.         Journal of High Speed Networks
  429.  
  430. Magazines
  431. =========
  432.         Communications Week
  433.         Data Communications
  434.         Open Systems Today
  435.  
  436.  
  437. SUBJECT:  C2)   Where/What is the "Network Compatible ATM for Local Network 
  438.                 Applications" document?
  439.  
  440. "Network Compatible ATM for Local Network Applications", V1.01, October 19, 
  441. 1992.  A proposal for a 150 Mb ATM LAN from Apple, Bellcore, Sun and Xerox.
  442. Available in standard postscript and compressed standard postscript from:
  443.  
  444. thumper.bellcore.com: /pub/nclatm/nclatm.ps
  445.                       /pub/nclatm/nclatm.ps.Z
  446. ftp.apple.com:        /pub/latm/nclatm.ps
  447.                       /pub/latm/nclatm.ps.Z
  448. parcftp.xerox.com:    /pub/latm/nclatm.ps
  449.                       /pub/latm/nclatm.ps.Z
  450.  
  451.  
  452. SUBJECT:  C3)   Where are hosts with ATM related information?
  453.  
  454.     Here's a list of sites that that seem to cater to the 
  455. ATM/broadband/real-time continuous-media crowd:
  456.  
  457. cc-hw.bbn.com                Rec_I_cls.ps, Rec_I_cls.hqx
  458. icsi-ftp.Berkeley.EDU        Research, Continuous media
  459. wuarchive.wustl.edu          Research, ATM Hardware
  460. datanet.tele.fi              Standards drafts (see below)
  461. nsco.network.com             HIPPI
  462. gregorio.stanford.edu        IP Multicast
  463. cell-relay.indiana.edu       cell-relay archives, etc. (see below)
  464.  
  465. If you have ftp access, ftp to cell-relay.indiana.edu as user anonymous and 
  466. look in /pub/cell-relay for:
  467.  
  468.         1) In /pub/cell-relay/bib
  469.            A bibliography of ATM research.  This includes several to 
  470.            reference books and LOTS of citations.
  471.         2) In /pub/cell-relay/docs
  472.            Some papers on ATM-related topics, standards, etc.
  473.         3) In /pub/cell-relay
  474.            This FAQ list!
  475.         4) In /pub/cell-relay/conferences
  476.            A bunch of files describing upcoming conferences
  477.  
  478. (Special thanks to Allen Robel for hosting this list and archive.)
  479.  
  480. Additionally, there are some draft standards, RFCs, technical papers, etc.
  481. on ATM available at datanet.tele.fi in the directory called /atm
  482. The collection includes draft AAL5 CCITT standards.  This is a general good
  483. place to look.
  484.  
  485.  
  486. SUBJECT:  C4) * How can I get the ATM Forum's Interface Specifications?
  487.  
  488.     The ATM Forum has produced a document called the User-Network
  489. Interface specification.  This document applies to both the "Private UNI" 
  490. between an ATM user and a private ATM switch, and also a "Public UNI" between
  491. a private ATM switch or a user and the public network.  The specification
  492. contains information on the ATM bearer services, physical level interface
  493. options, local network management, traffic, and signalling for both the 
  494. private and public UNIs.
  495.  
  496. For those which are not ATM Forum members, hard copies will be available
  497. for purchase at book stores and direct from Prentice Hall.  This specification
  498. is due to be published by Prentice Hall on 12/15/93 and will cost $34.  It
  499. can be backordered now.  To do this call 1-800-374-1200 and ask for the 
  500. following book:
  501.  
  502. Title:  ATM User-Network Interface Specification
  503. Author: ATM Forum
  504. ISBN:   0-132-25863-3
  505.  
  506. The ATM Forum's DXI and B-ICI specification can be ordered directly from the 
  507. ATM Forum.  Call the ATM Forum information line for ordering information 
  508. (415) 962-2585.  See also subject B1.
  509.  
  510.  
  511. SUBJECT:  C5) * List of ITU-TS recommendations concerning ATM
  512.  
  513.     This list is provided for informational purposes only.  No guarantee
  514. as to its completeness or correctness.  Also, although they are not formally 
  515. published, many of the following recommendations have been substantially
  516. updated since first published.  
  517.  
  518. You can buy these on paper from the ITU:
  519.     ITU
  520.     Place des Nations
  521.     CH-1211 Geneva 20
  522.     Switzerland.
  523. The fax number of the sales office is +41 22 730 5194.  They are also
  524. available commercially from at least 2 sources in the U.S.:
  525.  
  526.     Information Gatekeepers in Boston, MA (1-800-323-1088)
  527.     Phillipps Publishing  (1-800-OMNICOM)
  528.  
  529. Phillips usually has documents in stock & has fast delivery.
  530.  
  531.     =ITU-TS Recommendations Concerning ATM =
  532.  
  533. E.164      Numbering plan for the ISDN era                   11/91
  534. G.707      Synchronous digital hierarchy bit rates           04/91
  535. G.708      Network node interface for the synchronous        06/92
  536.        digital hierarchy
  537. G.709      Synchronous multiplexing structure                06/92
  538. I.113      B-ISDN Vocabulary of Terms                        04/91
  539. I.121R     Broadband Aspects Of ISDN                         04/91
  540. I.150      B-ISDN asynchronous transfer mode functional      06/92
  541.        characteristics
  542. I.211      B-ISDN service aspects                            04/91
  543. I.311      B-ISDN General Network aspects                    06/92
  544. I.321      B-ISDN protocol reference model and its           04/91
  545.        application
  546. I.327      B-ISDN functional architecture                    04/91
  547. I.361      B-ISDN ATM layer specification                    06/92
  548. I.362      B-ISDN ATM  adaptation layer (AAL) functional     04/91
  549.        description
  550. I.363      B-ISDN ATM adaptation layer (AAL) specification   06/92
  551. I.413      B-ISDN user-network interface                     04/91
  552. I.432      B-ISDN user-network interface - Physical layer    06/92
  553.        specification
  554. I.610      OAM principles of the B-ISDN access               06/92
  555.  
  556.  
  557.  
  558. Also, there are draft recommendations yet to be published (or I am just not
  559. sure of their status):
  560.  
  561. I.35B   BISDN ATM Layer Cell Transfer Performance, 1992
  562. I.363   Temp Doc 10 (XVIII) 'AAL Type 5 , Draft Recommendation text for
  563.                              ssection 6 of I.363"  06/93
  564. I.364    Temp Doc 58 (XVIII) 'Support of Broadband Connectionless Data
  565.                              Service on B-ISDN'  06/92
  566. I.365.1 Frame Relaying Service Specific Convergence Sublayer (FR-SSCS) 06/93
  567. I.371    Temp Doc 64 (XVIII) 'Traffic Control and Congestion Control in
  568.                              B-ISDN'  05/92
  569. I.555   Frame Relaying Bearer Service Interworking  06/93
  570. Q.93B   B-ISDN User-Network Interface Layer 3 Specification for Basic
  571.         Call/Bearer Control,  04/93
  572. Q.931   ISDN user-network interface layer 3 specification for basic 
  573.         call control  05/92
  574. Q.933   Digital Subscriber Signalling Systems No. 1 (DSS 1) Signalling
  575.         Specification for Frame Mode Basic Call Control  05/92             
  576. G.804   Which describes the mapping of ATM cells into PDH links at 1.544,
  577.         2.048, 6.312, 34.368, 44.736, 97.728, 139.264 Mb/s (Jan 1993)
  578.  
  579.  
  580.  
  581. SUBJECT:  C6) * Internet drafts from IETF working groups.
  582.  
  583.         Various work items of the IP over Asynchronous Transfer Mode Working
  584. group and other working groups of the IETF currently available include:
  585.  
  586.         draft-ietf-atm-address-resolve-00.txt
  587.         draft-ietf-atm-address-translation-00.txt
  588.         draft-ietf-atm-classic-ip-05.txt
  589.         draft-ietf-atm-mtu-05.txt
  590.         draft-heinanen-nhrp-01.txt
  591.         draft-ietf-iplpdn-directed_arp-01.txt
  592.         draft-ietf-atm-multipro-06.txt
  593.         draft-ietf-atm-nmba-01.txt
  594.         draft-ietf-rolc-nhrp-00.txt
  595.         draft-ietf-atommib-atm-01.txt
  596.  
  597. Internet-Drafts are available by anonymous FTP.  Internet-Drafts directories 
  598. are located at:    
  599.                                                     
  600.      o  East Coast (US) ds.internic.net (198.49.45.10)
  601.      o  Pacific Rim     munnari.oz.au (128.250.1.21)    
  602.      o  Europe          nic.nordu.net (192.36.148.17)    
  603.                                                     
  604. Internet-Drafts are also available by mail.  Send a message to:  
  605. mail-server@nisc.sri.com.  In the body specify the filename requested.  For
  606. example type: "SEND draft-ietf-atm-multipro-06.txt".
  607.  
  608.  
  609. SUBJECT:  C7) * ATM Tutorials.
  610.  
  611.         The following ATM tutorials are available via anonymous FTP.
  612.  
  613.     Machine:  ftp.magic.net
  614.     Path:     pub/magic
  615.     File:     ip-atm.ps   (PostScript)
  616.               ip-atm.ps.Z (Compressed PostScript)
  617. The focus of this paper is running IP over ATM, but there is an extensive
  618. tutorial on ATM, followed by discussion IP over ATM networks.
  619.  
  620.  
  621.     Machine:  datanet.tele.fi
  622.     Path:     atm/articles
  623.     File:     atm-intro.txt
  624. This paper is also a good starting point.
  625.  
  626. And a the following publically available paper is a good start:
  627. "The Asynchronous Trnasfer Mode: A Tutorial" by Jean-Yves Le Boudec
  628. in Computer Networks and ISDN, Vol 24, No 4, May 1992, pp 279-309
  629.  
  630. Additionally there are reasonable tutorials available from three commercial
  631. communications companies.  Specifically:
  632.  
  633. 1. "ATM In Private Networking", Anthony Alles, Hughes LAN Systems, Spring 1993
  634.    This was handed out at the Spring 1993 Interop for free.  Contact 
  635.    Hughes LAN Systems, Inc., 1225 Charleston Road, Mountain View, CA 94043.  
  636.    Phone: (415) 966-7330  Fax: (415) 960-3738  (Note no guarentee that they 
  637.    will send out a copy.)
  638.  
  639. 2. "Asynchronous Transfer Mode: Bandwidth for the Future", Jim Lane, Telco 
  640.    Systems, 1992.  To order a free copy simply call 1-800-447-2537
  641.  
  642. 3. "Broadband Testing Technologies", (a HP Seminar Handbook), Hewlett-
  643.    Packard Company, February 1993, Document number 5091-6902E
  644.    Call your local HP sales office and or contact the HP IDACOM Test
  645.    division.  The inside cover claims this document costs $10.
  646.  
  647.  
  648. SUBJECT:  C8)   Contact information for ANSI T1S1 specifications.
  649.  
  650.         These documents can be obtained directly from the Secretariat for
  651. the ANSI T1 Telecommunications committee.  
  652.  
  653.         Exchange Carriers Standard Association
  654.         1200 G. Street N.W.  Suite 500
  655.         Washington, D.C. 20005
  656.  
  657. All orders and requests for quotations on prices must be in writing.  Their
  658. FAX number is: (202) 393-5453
  659.  
  660.  
  661. SUBJECT:  C9)   Internet RFCs
  662.  
  663.         The following RFCs are available related to cell-relay technology.
  664.  
  665.         RFC 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5
  666.  
  667.  
  668. SUBJECT:  C10) + ATM and Related Acronyms
  669.  
  670.         These are a few acronyms which tend to appear in postings, RFCs, 
  671. standards and other text related to the cell-relay topic area.
  672.  
  673. AAL     ATM Adaptation Layer          
  674. ATM     Asynchronous Transfer Mode
  675. BISDN   Broadband Integrated Services Digital Network
  676. CBR     Constant Bit Rate
  677. CLP     Cell Loss Priority (as in CLP bit)
  678. CPCS    Common Part Convergence Sublayer
  679. CS      Convergence Sublayer (as in CS_PDU)
  680. DXI     Data Exchange Interface (as in ATM DXI)
  681. GFC     Generic Flow Control
  682. HEC     Header Error Control
  683. ILMI    Interim Local Management Interface
  684. NLPID   Network Layer Protocol ID
  685. NNI     Network Node Interface
  686. NSAP    Network Layer Service Access Point
  687. PDU     Protocol Data Unit
  688. PLCP    Physical Layer Convergence Procedure
  689. PTI     Payload Type Identifer
  690. PVC     Permanent Virtual Circuit
  691. QOS     Quality of Service
  692. SAR     Segmentation and Reassembly (as in SAR_PDU)
  693. SDH     Synchronous Digital Hierarchy
  694. SDU     Service Data Unit (as in AAL_SDU)
  695. SIR     Sustained Information Rate
  696. SMDS    Switched Multi-Megabit Data Service
  697. SNAP    SubNetwork Attachment Point (see IEEE 802.1a)
  698. SNI     Subscriber Network Interface
  699. SSCS    Service Specific Convergence Sublayer
  700. SSCOP   Service Specific Connection Oriented Protocol
  701. SVC     Switched Virtual Circuit
  702. UNI     User to Network Interface
  703. VBR     Variable Bit Rate
  704. VC      Virtual Channel (not circuit)
  705. VCC     Virtual Channel Connection
  706. VCI     Virtual Channel Identifier
  707. VP      Virtual Path
  708. VPC     Virtual Path Connection
  709.  
  710.  
  711. Here are a few five dollar words which sometime come arise in this topic area.
  712.  
  713. Plesiochronous: Signals which are arbitrarily close in frequency to some
  714.    defined precision.  They are not sourced from the same clock and so, over
  715.    the long term, will be skewed from each other.  Their relative closeness of
  716.    allows a switch to cross connect, switch, or in some way processs
  717.    them.  That same inaccuracy of timing will force a switch, over time, to 
  718.    repeat or delete frames (called frame slips) in order to handle buffer 
  719.    underflow or overflow.
  720.  
  721. Synchronous: Signals that are sourced from the same timing reference.  These
  722.    have the same frequency. (Contrast with Plesiochronous signals)
  723.  
  724. Asynchronous: Signals that are sourced from independent clocks.  These signals
  725.    generally have no relation to each other and so have different frequencies
  726.    and phase relationships.  (Contrast with Plesiochronous signals)
  727.  
  728. Isochronous: Signals which are dependant on some uniform timing or carry
  729.    their own timing information embedded as part of the signal.
  730.  
  731.         
  732. -----------------------------------------------------------------------------
  733. TOPIC:     D)   ATM TECHNOLOGY QUESTIONS    
  734. -----------------------------------------------------------------------------
  735. SUBJECT:  D1)   What are the various ATM Adaptation layers?
  736.  
  737.     In order for ATM to support many kinds of services with different
  738. traffic characteristics and system requirements, it is necessary to adapt
  739. the different classes of applications to the ATM layer.  This function is
  740. performed by the AAL, which is service-dependent.  Four types of AAL were
  741. originally recommended by CCITT.  Two of these have now been merged
  742. into one.  Also, within the past year a fifth type of AAL has been proposed.
  743.  
  744.     Briefly the four ATM adaptation layers (AAL) have/are being defined:
  745.  
  746. AAL1 - Supports connection-oriented services that require constant bit rates
  747.        and have specific timing and delay requirements.  Example are constant
  748.        bit rate services like DS1 or DS3 transport.
  749.  
  750. AAL2 - Supports connection-oriented services that do not require constant
  751.        bit rates.  In other words, variable bit rate applications like
  752.        some video schemes.
  753.  
  754. AAL3/4 - This AAL is intended for both connectionless and connection oriented
  755.        variable bit rate services.  Originally two distinct adaptation layers
  756.        AAL3 and 4, they have been merged into a single AAL which name is
  757.        AAL3/4 for historical reasons.
  758.  
  759. AAL5 - Supports connection-oriented variable bit rate data services.  It is
  760.        a substantially lean AAL compaired with AAL3/4 at the expense of
  761.        error recovery and built in retransmission.  This tradeoff provides
  762.        a smaller bandwidth overhead, simpler processing requirements, and
  763.        reduced implementation complexity.  Some organizations have proposed
  764.        AAL5 for use with both connection-oriented and connectionless services.
  765.  
  766. A recent document which describes these (except AAL2) with frame formats is:
  767. "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols
  768. Generic Requirements",  Bellcore Technical Advisory, TA-NWT-001113, Issue 1,
  769. August 1992.  This can be obtained by writing to:
  770.  
  771.     Bellcore
  772.     Document Registrar
  773.     445 South Street - Rm. 2J125
  774.     P.O. Box 1910
  775.     Morristown, NJ  07962-1910
  776.  
  777. SUBJECT:  D2)   Are ATM cells delivered in order?
  778.  
  779.     Yes.  The ATM standards specify that all ATM cells will be delivered
  780. in order.  Any switch and adaptation equipment design must take this into
  781. consideration.
  782.  
  783.  
  784. SUBJECT:  D3)   What do people mean by the term "traffic shaping"?
  785.  
  786.         Here is an explicit definition of traffic shaping followed by brief
  787. tutorial.  Note that a variety of techniques have been investigated to 
  788. implement traffic shaping.  Reference the literature for keywords such as 
  789. "leaky bucket", "congestion", "rate control", and "policing".
  790.  
  791. Definition:
  792. Traffic shaping is forcing your traffic to conform to a certain 
  793. specified behavior.  Usually the specified behavior is a worst case or a 
  794. worst case plus average case (i.e., at worst, this application will generate 
  795. 100 Mbits/s of data for a maximum burst of 2 seconds and its average over 
  796. any 10 second interval will be no more than 50 Mbit/s).
  797.  
  798. Of course, understand that the specified behavior may closely match the
  799. way the traffic was going to behave anyway.  But by knowing precisely
  800. how the traffic is going to behave, it is possible to allocate resources
  801. inside the network such that guarantees about availability of bandwidth
  802. and maximum delays can be given.
  803.  
  804.  
  805. Brief Tutorial:
  806. Assume some switches connected together which are carrying traffic.
  807. The problem to actually deliver the grade of service that has been promised, 
  808. and that people are paying good money for. This requires some kind of resource
  809. management strategy, since congestion will be by far the greatest factor
  810. in data loss. You also need to charge enough to cover you costs and make a
  811. profit, but in such a way that you attract customers. There are a number
  812. of parameters and functions that need to be considered:
  813.  
  814. PARAMETERS
  815. ----------
  816. There are lots of traffic parameters that have been proposed for resource
  817. management. The more important ones are:
  818.     mean bitrate
  819.     peak bitrate
  820.     variance of bitrate
  821.     burst length
  822.     burst frequency
  823.     cell-loss rate
  824.     cell-loss priority
  825.     etc. etc.
  826.  
  827. These parameters exist in three forms:
  828.     (a) actual
  829.     (b) measured, or estimated
  830.     (c) declared (by the customer)
  831.  
  832. FUNCTIONS
  833. ---------
  834. (a) Acceptance Function
  835. -----------------------
  836. Each switch has the option of accepting a virtual circuit request based on
  837. the declared traffic parameters as given by the customer. Acceptance is
  838. given if the resulting traffic mix will not cause the switch to not
  839. achieve its quality of service goals.
  840.  
  841. The acceptance process is gone through by every switch in a virtual
  842. circuit. If a downstream switch refuses to accept a connection, an
  843. alternate route might be tried.
  844.  
  845. (b) Policing Function
  846. ---------------------
  847. Given that a switch at the edge of the network has accepted a virtual
  848. circuit request, it has to make sure the customer equipment keeps its
  849. promises. The policing function in some way estimates the the parameters
  850. of the incoming traffic and takes some action if they measure traffic
  851. exceeding agreed parameters. This action could be to drop the cells, mark
  852. them as being low cell-loss priority, etc.
  853.  
  854. (c) Charging Function
  855. ---------------------
  856. The function most ignored by traffic researchers, but perhaps the most
  857. important for the success of any service! Basically, this function
  858. computes a charge from the estimated and agreed traffic parameters.
  859.  
  860. (d) Traffic Shaping Function
  861. ----------------------------
  862. Traffic shaping is something that happens in the customer premise equipment.
  863. If the Policing function is the policeman, and the charging function is the
  864. judge, then the traffic shaper is the lawyer. The traffic shaper uses
  865. information about the policing and charging functions in order to change
  866. the traffic characteristics of the customer's stream to get the lowest
  867. charge or the smallest cell-loss, etc.
  868.  
  869. For example, an IP router attached to an ATM network might delay some
  870. cells slightly in order to reduce the peak rate and rate variance without
  871. affecting throughput. An MPEG codec that was operating in a situation
  872. where delay wasn't a problem might operate in a CBR mode.
  873.  
  874. Game theory buffs will note that the charging function and the shaping
  875. function form a 2-player game.
  876.  
  877.  
  878.  
  879. SUBJECT:  D4)   What is happening with signalling standards for ATM?
  880.  
  881.         The Signaling Sub-Working Group of the ATM Forum's Technical 
  882. Committee has completed its implementation agreement on signaling at the 
  883. ATM UNI.  The protocol is based on Q93B with extensions 
  884. to support point-to-multipoint connections.  Agreements on addressing specify 
  885. the use of GOSIP-style NSAPs for the (SNPA) address of an ATM end-point 
  886. at the Private UNI, and the use of either or both GOSIP-style NSAPs and/or 
  887. E.164 addresses at the Public UNI.  The agreements have been documented 
  888. as part of an updated (3.0) UNI specification. 
  889.  
  890. Additionally, the ANSI T1S1 as well as the CCITT sudygroup XI are concerned 
  891. with ATM signalling. 
  892.  
  893.  
  894. SUBJECT:  D5)   What is VPI and VCI?
  895.  
  896.         ATM is a connection orientated protocol and as such there is a 
  897. connection identifier in every cell header which explicitly associates a cell 
  898. with a given virtual channel on a physical link.  The connection identifier 
  899. consists of two sub-fields, the Virtual Channel Identifier (VCI) and the 
  900. Virtual Path Identifier (VPI).  Together they are used in multiplexing, 
  901. demultiplexing and switching a cell through the network.  VCIs and VPIs are 
  902. not addresses.  They are explicitly assigned at each segment (link between ATM
  903. nodes) of a connection when a connection is established, and remain for the 
  904. duration of the connection.  Using the VCI/VPI the ATM layer can 
  905. asynchronously interleave (multiplex) cells from multiple connections.
  906.  
  907.  
  908. SUBJECT:  D6)   Why both VPI *and* VCI?
  909.  
  910.         The Virtual Path concept originated with concerns over the cost of 
  911. controlling BISDN networks.  The idea was to group connections
  912. sharing common paths through the network into identifiable units (the Paths).
  913. Network management actions would then be applied to the smaller number of 
  914. groups of connections (paths) instead of a larger number of individual 
  915. connections (VCI).  Management here including call setup, routing, failure
  916. management, bandwidth allocation etc.  For example, use of Virtual Paths in
  917. an ATM network reduces the load on the control mechanisms because the function
  918. needed to set up a path through the network are performed only once for all
  919. subsequent Virtual Channels using that path.  Changing the trunk mapping
  920. of a single Virtual Path can effect a route change for every Virtual Channel
  921. using that path.
  922.  
  923. Now the basic operation of an ATM switch will be the same, no matter if it is
  924. handling a virtual path or virtual circuit.  The switch must identify on
  925. the basis of the incomming cell's VPI, VCI, or both, which output port to
  926. forward a cell received on a given input port.  It must also determine what
  927. the new values the VPI/VCI are on this output link, substituting these 
  928. new values in the cell.
  929.  
  930.  
  931. SUBJECT:  D7)   How come an ATM cell is 53 bytes anyway?
  932.  
  933.         ATM cells are standardized at 53 bytes because it seemed like a 
  934. good idea at the time!  As it turns out, during the standardization process
  935. a conflict arose within the CCITT as to the payload size within an ATM
  936. cell.  The US wanted 64 byte payloads because it was felt optimal for
  937. US networks.  The Europeans and Japanese wanted 32 payloads because it was
  938. optimal for them.  In the end 48 bytes was chosen as a compromise.  So 
  939. 48 bytes payload plus 5 bytes header is 53 bytes total. 
  940.  
  941. The two positions were not chosen for similar applications however.
  942. US proposed 64 bytes taking into consideration bandwidth utilization for
  943. data networks and efficient memory transfer (length of payload should be 
  944. a power of 2 or at least a multiple of 4). 64 bytes fit both requirements.
  945.  
  946. Europe proposed 32 bytes taking voice applications into consideration. At
  947. cell sizes >= 152, there is a talker echo problem. Cell sizes between 32-152
  948. result in listener echo. Cell sizes <= 32 overcome both problems, under ideal
  949. conditions. 
  950.  
  951. CCITT chose 48 bytes as a compromise. As far as the header goes, 10% of
  952. payload was perceived as an upper bound on the acceptable overhead, so 5 bytes
  953. was chosen.
  954.  
  955.  
  956. SUBJECT:  D8)   How does AAL5 work?
  957.  
  958.         Here is is a very simplified view of AAL5 and AALs in general.
  959. AAL5 is a mechanism for segmentation and reassembly of packets.  That is, 
  960. it is a rulebook which sender and receiver agree upon for taking a long 
  961. packet and dividing it up into cells.  The sender's job is to segment the
  962. packet and build the set of cells to be sent.  The receiver's job is to
  963. verify that the packet has been received intact without errors and to
  964. put it back together again.
  965.  
  966. In AAL5, a packet is segmented as follows:
  967.  
  968.    - The packet is divided up into 48 byte chunks -- each chunk is
  969. placed into a separate cell (carried on the same VCI)
  970.  
  971.    - If the last chunk is from 1 to 40 bytes, then the last eight
  972. bytes in that cell are filled with the AAL5 trailer (2 bytes reserved,
  973. 2 bytes of packet length, and 4 bytes of CRC).  (If the last chunk is
  974. less than 40 bytes, then padding is added to place the trailer at the
  975. end of the cell.)
  976.  
  977.    - If the last chunk is from 41 to 48 bytes, then that chunk is
  978. placed into a cell and an additional cell is added.  In that additional
  979. cell, the last eight bytes are used for the AAL5 trailer and the rest
  980. is padding.
  981.  
  982.    - The payload type in the last cell (i.e., wherever the AAL5 trailer
  983. is) is marked to indicate that this is the last cell in a packet.  (The
  984. receiver may assume that the next cell received on that VCI is the
  985. beginning of a new packet.)
  986.  
  987. There are two problems that can happen during transit.  First, a
  988. cell could be lost.  In that case, the receiver can detect the problem
  989. either because the length does not correspond with the number of cells
  990. received, or because the CRC does not match what is calculated.  Second,
  991. a bit error can occur within the payload.  Since cells do not have any
  992. explicit error correction/detection mechanism, this cannot be detected
  993. except through the CRC mismatch.
  994.  
  995. Note that it is up to higher layer protocols to deal with lost and
  996. corrupted packets.  Most people assume that a corrupted packet will be
  997. handled by discarding it and treating it as if it were lost.
  998.  
  999.  
  1000.  
  1001. SUBJECT:  D9)   What are the diffferences between Q.93B and Q.931?
  1002.  
  1003.         Essentially, Q.93B is an enhanced signalling protocol for call
  1004. control at the Broadband-ISDN user-network interface, using the ATM
  1005. transfer mode.  The most important difference is that unlike Q.931
  1006. which manages fixed bandwidth circuit switched channels, Q.93B has
  1007. to manage variable bandwidth virtual channels.  So, it has to deal
  1008. with new parameters such as ATM cell rate, AAL parameters (for
  1009. layer 2), broadband bearer capability, etc.  In addition, the ATM
  1010. Forum has defined new functionality such as point-to-multipoint
  1011. calls.  The CCITT Recommendation will specify interworking
  1012. procedures for narrowband ISDN.
  1013.  
  1014.  
  1015.  
  1016. -----------------------------------------------------------------------------
  1017. TOPIC:     E)   TOPIC: ATM VS. XYZ TECHNOLOGY
  1018. -----------------------------------------------------------------------------
  1019. SUBJECT:  E1)   How does ATM differ from SMDS?
  1020.  
  1021.     SMDS is the Switched Multimedia Data Service, a service offering 
  1022. interface from Bellcore.  SMDS provides a datagram service, where a packet has
  1023. about a 40-octet header plus up to 9188 octets of data. The packets themselves
  1024. may or may not be transported within the network on top of a connection-
  1025. oriented ATM service.  SMDS uses E.164 (ISDN) addresses.  Therefore SMDS is
  1026. a connectionless packet switched *service*, not a cell-relay service.
  1027.  
  1028. HOWEVER, the SMDS Subscriber Network Interface is currently defined to use 
  1029. IEEE 802.6 Distributed Queue Dual Bus (DQDB) access across the SMDS 
  1030. user-network interface.  DQDB itself *is* a form of cell relay.  The lower 
  1031. layers of SMDS fragment the packets into cells with a 5-octet header and 
  1032. 48-octet payload.  The payload itself has a 2-octet header, 44-octets of data,
  1033. plus a 2-octet trailer.  An SMDS cell therefore is nearly identical in form 
  1034. to an AAL3/4 cell.
  1035.  
  1036. Note that while DQDB is used as the aaccess protocol, either DQDB or AAL3/4
  1037. may be used for the switch-to-switch interface.
  1038.  
  1039. -----------------------------------------------------------------------------
  1040. TOPIC:     F) + TOPIC: FREELY AVAILABLE REFERENCE IMPLEMENTATIONS
  1041. -----------------------------------------------------------------------------
  1042. SUBJECT:  F1) + What and where is VINCE?
  1043.  
  1044.          Vince has now on record as the first "publicaly available" software
  1045. source code in the ATM technology area.  This work was carried out by the 
  1046. Research Networks section of the Center for Computational Science at the
  1047. Naval Research Laboratory, with support from the Advanced Research Projects
  1048. Agency and NAVSEA.  In the Grand Internet Tradition, these fine folks have
  1049. contributed their efforts to the community in support of further research.
  1050.  
  1051.          The following is from the October 14, 1993 posting announcing the
  1052. availability of VINCE....
  1053.  
  1054. VINCE RELEASE 0.5 ALPHA
  1055.  
  1056. Vince, the Vendor Independent Network Control Entity, is 
  1057. publicly available (in source code form) as an 
  1058. alpha release. Its primary function is to perform ATM 
  1059. signalling and VC management tasks. It currently includes
  1060. a hardware module that allows it to run on Fore ASX-100(tm)
  1061. switches.  Other hardware modules are under development.
  1062.  
  1063. Vince consists of a core which provides basic ATM network
  1064. semantics, and modules to perform specific functions. Modules
  1065. included in this release are:
  1066.  
  1067.   spans  - module which intereroperates signalling and routing
  1068.            with Fore Systems ASX switch and various host interfaces.
  1069.            SPANS is (tm) Fore Systems, Inc.
  1070.  
  1071.   q93b   - an implementation of signalling as specified in the ATM
  1072.            Forum UNI 3.0 document.  The vince core includes sscop 
  1073.            and aal5 in its protocol library.
  1074.  
  1075.   sim    - a software ATM switch or host that can be used to test 
  1076.            signalling and routing implementations without ATM 
  1077.            hardware. 
  1078.  
  1079.   sroute - an address independent VC routing module.
  1080.  
  1081. The Vince distribution also contains a driver that uses spans for
  1082. signalling and supports the Fore Systems SBA-100 under SunOS(tm).
  1083.  
  1084. Work has already begun on a kernel version of Vince, which will 
  1085. allow ATM Forum UNI signalling for hosts.  Also in development
  1086. are SNMP/ILMI support, interdomain routing, and support for other 
  1087. switches.
  1088.  
  1089. The intent is to provide a redistributable framework which
  1090. allows for code sharing among ATM protocol developers.
  1091.  
  1092. Vince and its architecture document are available for 
  1093. anonymous ftp at hsdndev.harvard.edu:pub/mankin
  1094.            vince_0.5a.tar.Z.
  1095.  
  1096. A mailing list for Vince developers and users can be joined 
  1097. by sending mail to vince-request@cmf.nrl.navy.mil.
  1098.  
  1099.          
  1100.  
  1101. -----------------------------------------------------------------------------
  1102. CONTRIBUTORS
  1103.  
  1104. This FAQ is a collective work which has been compiled by and is maintained 
  1105. by Carl Symborski.  The information contained herein has been gathered from 
  1106. a variety of sources.  Most derived from a consensus of postings on the 
  1107. cell-relay group.  The following individuals have provided direct 
  1108. contributions to this FAQ, either by posting to the cell-relay list or
  1109. by private EMail coorespondance.  If you would like to claim responsibility 
  1110. for a particular item, please let me know.
  1111.  
  1112. Kingston Duffie, kduffie@netcom.com
  1113. A. Gavras, ag@fokus.gmd.de
  1114. Rajeev Gupta, r_gupta@trillium.com
  1115. Matthew Maa, maa@edsdrd.eds.com
  1116. Craig Partridge, craig@bbn.com
  1117. Allen Robel, robelr@indiana.edu
  1118. Lee D. Rothstein, ldr@veritech.com
  1119. Carl Symborski, carl@umd5.umd.edu
  1120. Mark Williams, miw@cc.uq.edu.au
  1121.  
  1122. ------ END OF FAQ -------
  1123.  
  1124.  
  1125.